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ENUM Validation Information Mapping 
for the Extensible Provisioning Protocol 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document describes an Extensible Provisioning Protocol (EPP) 
extension framework for mapping information about the validation 
process that has been applied for the E.164 number (or number range) 
that the E.164 Number Mapping (ENUM) domain name is based on. 
Specified in the Extensible Markup Language (XML), this mapping 
extends the EPP domain name mapping to provide an additional feature 
required for the provisioning of ENUM Domain Names. 
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1. Introduction 


This document describes a framework for an ENUM [2] validation 
information mapping for version 1.0 of EPP [3]. This mapping, an 
extension of the EPP domain name mapping described in [4], is 
specified using XML 1.0, as described in [5], and XML Schema 
notation, as described in [6] and [7]. 


The EPP core protocol specification [3] provides a complete 
description of EPP command and response structures. A thorough 
understanding of the base protocol specification is necessary to 
understand the mapping described in this document. 
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ENUM [2] describes how the Domain Name System (DNS) can be used to 
identify services associated with an E.164 number. 


As described in REC 4725 [9], usually only the Assignee of the E.164 
number (or number range) has the right to register the corresponding 
ENUM domain name. Therefore, an ENUM validation process has to be 
applied before the ENUM domain name can be inserted into the DNS. 
The validation process shall ensure that the holder of the ENUM 
domain name coincides with the Assignee of the corresponding E.164 
number (or number range). However, the details of the ENUM 
validation methods are beyond the scope of this document. 


The EPP extension described in this document specifies a framework 
for the mapping of information about the ENUM validation process. As 
the local legislation or the validation procedures may vary, the 
content of the validation information itself is not part of this 
specification. 


However, this document contains a working example (including XML 
schema) to show how the validation information could look. This 
example could even be used for a lightweight validation process. In 
fact, it has been an integral part of the Swiss ENUM trial. 


Using this extension framework, the content of the validation 
information can be specified according to the local requirements. 
Such an extension is specified in [10]. 


More background information concerning the validation can be found in 
REC 4725 [9], which also describes a typical basic role model for the 
ENUM registration process. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


In examples, "C:" represents lines sent by a protocol client and "S:" 
represents lines returned by a protocol server. Indentation and 
white space in examples are provided only to illustrate element 
relationships and are not REQUIRED features of this specification. 


XML is case sensitive. Unless stated otherwise, XML specifications 
and examples provided in this document MUST be interpreted in the 
character case presented to develop a conforming implementation. 
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3. Requirements 
The following requirements are the basis for this work: 


1. The design shall allow multiple policies and validation 
procedures. 


2. It shall be possible to transmit validation information with EPP 
domain object requests and responses. 


3. It shall be possible to add, modify, and remove validation 
information. 


4. It shall be possible to retrieve validation information stored in 
the ENUM Registry. 


4. Object Attributes 


This extension adds additional elements to the EPP domain name 
mapping [4]. Only new element descriptions are listed here. 


4.1. ENUM Domain Names 
An ENUM Domain Name is a representation of an E.164 number that has 
been translated to conform to domain name syntax as described in the 
ENUM specification [2]. 


4.2. Validation Information Commands 


The following commands are defined for handling validation 
information at the registry: 


o add: to add new validation information 
o rem: to revoke validation information 
o chg: to change stored validation information 
o inf: to get information about stored validation information 
4.3. Id 
The "id" attribute, used to identify the validation, is represented 
in this mapping using a character string. It MUST be unique at least 
within the same ENUM Domain Name. To ensure uniqueness even after a 


transfer of an ENUM Domain Name, it is RECOMMENDED that the "id" 
attribute be unique per ENUM Registry. 
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The "id" attribute, usually assigned by the ENUM Registrar, is 
required for revoking or changing stored validation information and 
appears in the Validation Information Command elements (see Section 
4.2). 


4.4. Validation Information 


The <validationInfo> element can contain any element containing 
validation information that is documented adequately. It is 
represented in this mapping using the XML schema <any> element and 
therefore, is extensible. 


The number of <validationInfo> elements permitted per domain object 
is subject to local policy. 


4.5. Validation Elements in the Example 


As described above, this document includes an example for a possible 
content of validation information that is used in the EPP examples 
throughout this document. 


This example is an optional part of this specification, i.e., a fully 
compliant RFC 5076 implementation does not need to implement this 
example. 


4.5.1. Method Identifier 


The <methodID> element is represented in this mapping using a 
character string with a maximum length of 63 characters. It contains 
an identifier for the method used for the validation. As stated in 
Section 1, the details of the ENUM validation methods are beyond the 
scope of this document. 


4.5.2. Validation Entity Identifier 


The <validationEntityID> element is represented in this mapping using 
a character string with a length of 3 to 16 characters. It contains 
an identifier assigned to the ENUM Validation Entity, e.g., by the 
ENUM Registry. 


4.5.3. Registrar Identifier 
The <registrarID> element is represented in this mapping using a 


character string with a length of 3 to 16 characters. It contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 
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4.5.4. Execution Date 


The <executionDate> element, the execution date of the validation, is 
represented in this mapping using the XML Schema ‘date’ data type. 


4.5.5. Expiration Date 


The <expirationDate> element, the expiration date of the validation, 
is represented in this mapping using the XML Schema ‘date’ data type. 


5. EPP Command Mapping 


A detailed description of the EPP syntax and semantics can be found 
in the EPP core protocol specification [3], and the EPP domain name 
mapping is described in [4]. The command mappings described here are 
specifically for use in implementing ENUM validation information 
provisioning processes via EPP. 


Note: Whether or not this extension is included into an EPP request 
or response depends on local policy. For example, a local Registry 
policy might require the use of this extension for EPP <create>, 
<update>, and <info> commands, but not support it for EPP <transfer> 
and <renew> commands. Therefore, this is beyond the scope of this 
document. 


5.1. EPP Query Commands 
EPP provides three commands to retrieve object information: <check> 
to determine if an object is known to the server, <info> to retrieve 
detailed information associated with an object, and <transfer> to 
retrieve object transfer status information. 


5.1.1. EPP <check> Command 


This extension does not add any elements to the EPP <check> command 
or <check> response described in the EPP domain mapping [4]. 


5.1.2. EPP <info> Command 


This extension does not add any elements to the EPP <info> command 
described in the EPP domain mapping [4]. Additional elements are 
defined for the <info> response. 


When an <info> command has been processed successfully, the EPP 
<resData> element MUST contain child elements as described in the EPP 
domain mapping [4]. In addition, the EPP <extension> element MUST 
contain an <el64val:infData> element that identifies the extension 
namespace. The <el64val:infData> element contains one or more 
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<el64val:inf> elements, each with an "id" attribute identifying the 
validation. Each <el64val:inf> element contains an <el64val: 
validationInfo> element, which contains the validation information as 
child element. 


In the example below, the validation information consists of a 
<valex:simpleVal> element that identifies the extension namespace. 
The <valex:simpleVal> element contains the following child elements: 


o An <el64val:methodID> element that contains an identifier of the 
validation method. 


o An OPTIONAL <el64val:validationEntityID> element that contains an 
identifier assigned to the ENUM Validation Entity. 


o An OPTIONAL <el64val:registrarID> element that contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 


o An <el64val:executionDate> element that contains the date that the 
validation was performed. 


o An OPTIONAL <el64val:expirationDate> element that contains the 
date that the validation expires. 


Example for <info> response: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<response> 
<result code="1000"> 
<msg>Command completed successfully</msg> 
</result> 
<resData> 
<domain:infData 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 
<domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> 
<domain:roid>EXAMPLE1-REP</domain:roid> 
<domain:status s="ok"/> 
<domain:registrant>jd1234</domain:registrant> 
<domain:contact type="admin">sh8013</domain:contact> 
<domain:contact type="tech">sh8013</domain:contact> 
<domain:ns> 
<domain:hostObj>nsl.example.com</domain:hostObj> 
<domain:hostObj>ns2.example.com</domain:hostObj> 
</domain:ns> 
<domain:clID>ClientX</domain:clID> 
<domain:crID>ClientY</domain:crID> 


naaa aa aaa aaa nn Un nn nn nun 
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<domain 


<trID> 


</trID> 


uuu aaa aaa a aaa aaa aa nnn nn unun Un 


:</epp> 


<domain: 


<domain: 
<domain: 
<domain: 
<domain: 
<domain : pw>2fooBAR</domain : pw> 
</domain:authInfo> 
</domain: 
</resData> 
<extension> 
<el64val: 
xmlns:el64val="urn:ietf:params:xml 
<el64val:inf id="EK77"> 
<el64val:validationInfo> 
<valex:simpleVal 
xmlns:valex="urn:ietf:params:xml:ns:el64valex-1.1"> 
methodID>Validation-X</valex:methodID> 
validationEntityID>VE-NMQ</valex:validationEntityID> 
registrarID>Client-X</valex:registrarID> 
executionDate>2004-04-08</valex:executionDate> 
expirationDate>2004-10-07</valex:expirationDate> 
</valex:simpleVal> 
</el64val:validationInfo> 
</el64val:inf> 
</el64val:infData> 
</extension> 


<valex: 
<valex: 
<valex: 
<valex: 
<valex: 


</response> 


ENUM Validation Mapping 


crDate>1999-04-03T22: 
:upID>ClientX</domain: 
upDate>1999-12-03T09: 
exDate>2005-04-03T22: 
trDate>2000-04-08T09: 


authInfo> 


infData> 


infData 


<c1TRID>ABC-23456</c1TRID> 
<svTRID>54321-XYZ</svTRID> 


00:00. 


upID> 


00:00. 
00:00. 
00:00. 


Figure 1 


5.1.3. EPP <transfer> Command 


for EPP 


0Z</domain: 
0Z</domain: 


0Z</domain: 
0Z</domain: 


ıns:el64val- 


December 2007 


crDate> 
upDate> 


exDate> 
trDate> 


1.0"> 


This extension does not add any elements to the EPP <transfer> 
command or <transfer> response described in the EPP domain mapping 


[4]. 
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5.2. EPP Transform Commands 


EPP provides five commands to transform objects: <create> to create 
an instance of an object, <delete> to delete an instance of an 
object, <renew> to extend the validity period of an object, 
<transfer> to manage object sponsorship changes, and <update> to 
change information associated with an object. 


5.2.1. EPP <create> Command 


This extension defines additional elements for the EPP <create> 
command described in the EPP domain mapping [4]. No additional 
elements are defined for the EPP <create> response. 


The EPP <create> command provides a transform operation that allows a 
client to create a domain object. In addition to the EPP command 
elements described in the EPP domain mapping [4], the command MUST 
contain an <extension> element. The <extension> element MUST contain 
an <el64val:create> element that identifies the extension namespace. 
The <el64val:create> element contains one or more <el64val:add> 
elements, each with an "id" attribute identifying the validation. 
Each <el64val:add> element contains an <el64val:validationInfo> 
element, which contains the validation information as child element. 


In the example below, the validation information consists of a 
<valex:simpleVal> element that identifies the extension namespace. 
The <valex:simpleVal> element contains the following child elements: 


o An <el64val:methodID> element that contains an identifier of the 
validation method. 


o An OPTIONAL <el64val:validationEntityID> element that contains an 
identifier assigned to the ENUM Validation Entity. 


o An OPTIONAL <el64val:registrarID> element that contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 


o An <el64val:executionDate> element that contains the date that the 
validation was performed. 


o An OPTIONAL <el64val:expirationDate> element that contains the 
date that the validation expires. 
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e for <create> command: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 


:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<command> 
<create> 


domain:create 

xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 
<domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> 
<domain:period unit="y">1</domain:period> 
<domain:ns> 
<domain:hostObj>nsl.example.com</domain:hostObj> 
<domain:hostObj>ns2.example.com</domain:hostObj> 
</domain:ns> 
<domain:registrant>jd1234</domain:registrant> 
<domain:contact type="admin">sh8013</domain:contact> 
<domain:contact type="tech">sh8013</domain:contact> 
<domain:authInfo> 
<domain : pw>2fooBAR</domain : pw> 

</domain:authInfo> 

/domain:create> 

create> 

xtension> 

el64val:create 

xmlns:el64val="urn:ietf:params:xml:ns:el64val-1.0"> 

<el64val:add id="EK77"> 

<el64val:validationInfo> 
<valex:simpleVal 

xmlns:valex="urn:ietf:params:xml:ns:el64valex-1.1"> 
<valex:methodID>Validation-X</valex:methodID> 


<valex:validationEntityID>VE-NMO</valex:validationEntityID> 


<valex:registrarID>Client-X</valex:registrarID> 
<valex:executionDate>2004-04-08</valex:executionDate> 
<valex:expirationDate>2004-10-07</valex:expirationDate> 
</valex:simpleVal> 
</elé64val:validationInfo> 

</el64val:add> 

/el64val:create> 

extension> 

1TRID>ABC-12345</c1TRID> 

ommand> 


p> 


Figure 2 


the EP 


Hoeneisen 


n extended <create> command has been processed successfully, 
P response is as described in the EPP domain mapping [4]. 
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5.2.2. EPP <delete> Command 


This extension does not add any elements to the EPP <delete> command 
or <delete> response described in the EPP domain mapping [4]. 


5.2.3. EPP <renew> Command 


This extension defines additional elements for the EPP <renew> 
command described in the EPP domain mapping [4]. No additional 
elements are defined for the EPP <renew> response. 


The EPP <renew> command provides a transform operation that allows a 
client to extend the validity period of a domain object. In addition 
to the EPP command elements described in the EPP domain mapping [4], 
the <renew> command MUST contain an <extension> element. The 
<extension> element MUST contain an <el64val:renew> element that 
identifies the extension namespace. The <el64val:renew> element 
contains one or more <el64val:add> elements, each with an "id" 
attribute identifying the validation. Each <el64val:add> element 
contains an <el64val:validationInfo> element, which contains the 
validation information as child element. 


In the example below, the validation information consists of a 
<valex:simpleVal> element that identifies the extension namespace. 
The <valex:simpleVal> contains the following child elements: 


o An <el64val:methodID> element that contains an identifier of the 
validation method. 


o An OPTIONAL <el64val:validationEntityID> element that contains an 
identifier assigned to the ENUM Validation Entity. 


o An OPTIONAL <el64val:registrarID> element that contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 


o An <el64val:executionDate> element that contains the date that the 
validation was performed. 


o An OPTIONAL <el64val:expirationDate> element that contains the 
date that the validation expires. 
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Example for <renew> command: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<command> 
<renew> 
<domain: renew 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 
<domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> 
<domain: curExpDate>2005-04-09</domain:curExpDate> 
<domain:period unit="y">1</domain:period> 
</domain: renew> 
</renew> 
<extension> 
<el64val: renew 
xmlns:el64val="urn:ietf:params:xml:ns:el64val-1.0"> 
<el64val:add id="CAB176"> 
<el64val:validationInfo> 
<valex:simpleVal 
xmlns:valex="urn:ietf:params:xml:ns:el64valex-1.1"> 
<valex:methodID>Validation-X</valex:methodID> 
<valex:validationEntityID>VE-NMO</valex:validationEntityID> 
<valex:registrarID>Client-X</valex:registrarID> 
<valex:executionDate>2005-03-30</valex:executionDate> 
<valex:expirationDate>2005-09-29</valex:expirationDate> 
</valex:simpleVal> 
</el64val:validationInfo> 
</el64val:add> 
</el64val : renew> 
</extension> 
<c1TRID>ABC-45678</c1TRID> 
</command> 
:</epp> 


9:0: :@79:09:0:0Q:0:90: 0-0.-.0790:079.2:2. A. aa A: AAIQ 


Figure 3 


When an extended <renew> command has been processed successfully, the 
EPP response is as described in the EPP domain mapping [4]. 
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5.2.4. EPP <transfer> Command 


This extension defines additional elements for the EPP <transfer> 
command described in the EPP domain mapping [4]. No additional 
elements are defined for the EPP <transfer> response. 


The EPP <transfer> command provides a transform operation that allows 
a client to manage requests to transfer the sponsorship of a domain 
object. Clients can initiate, cancel, approve, and reject a transfer 
request. 


In case of a transfer request, in addition to the EPP command 
elements described in the EPP domain mapping [4], the command MUST 


contain an <extension> element. The <extension> element MUST contain 
an <el64val:transfer> element that identifies the extension 
namespace. The <el64val:transfer> element contains one or more 


<el64val:add> elements, each with an "id" attribute identifying the 
validation. Each <el64val:add> element contains an <el64val: 
validationInfo> element, which contains the validation information as 
child element. 


In the example below, the validation information consists of a 
<valex:simpleVal> element that identifies the extension namespace. 


The <valex:simpleVal> contains the following child elements: 


o An <el64val:methodID> element that contains an identifier of the 
validation method. 


o An OPTIONAL <el64val:validationEntityID> element that contains an 
identifier assigned to the ENUM Validation Entity. 


o An OPTIONAL <el64val:registrarID> element that contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 


o An <el64val:executionDate> element that contains the date that the 
validation was performed. 


o An OPTIONAL <el64val:expirationDate> element that contains the 
date that the validation expires. 
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Example for <transfer> command: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<command> 
<transfer op="request"> 
<domain:transfer 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 
<domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> 
<domain:authInfo> 
<domain:pw roid="HB1973-ZUE">2fooBAR</domain :pw> 
</domain:authInfo> 
</domain:transfer> 
</transfer> 
<extension> 
<el64val:transfer 
xmlns:el64val="urn:ietf:params:xml:ns:el64val-1.0"> 
<el64val:add id="LJ1126"> 
<el64val:validationInfo> 
<valex:simpleVal 
xmlns:valex="urn:ietf:params:xml:ns:el64valex-1.1"> 
<valex:methodID>Validation-Y</valex:methodID> 
<valex:validationEntityID>VE2-LMO</valex:validationEntityID> 
<valex:registrarID>Client-Y</valex:registrarID> 
<valex:executionDate>2005-01-22</valex:executionDate> 
<valex:expirationDate>2005-07-21</valex:expirationDate> 
</valex:simpleVal> 
</el64val:validationInfo> 
</el64val:add> 
</el64val:transfer> 
</extension> 
<c1TRID>XYZ-54789</c1TRID> 
</command> 
:</epp> 


0 (40:4-:14-0. 0:11:00 OO) OG O'G.O:A5O. QO: O30. Oia: ACO (O: Aaa 


Figure 4 


When an extended <transfer> command has been processed successfully, 
the EPP response is as described in the EPP domain mapping [4]. 
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5.2.5. EPP <update> Command 


This extension defines additional elements for the EPP <update> 
command described in the EPP domain mapping [4]. No additional 
elements are defined for the EPP <update> response. The EPP <update> 
command provides a transform operation that allows a client to change 
the state of a domain object. In addition to the EPP command 
elements described in the EPP domain mapping [4], the <update> 
command MUST contain an <extension> element. The <extension> element 
MUST contain an <el64val:update> element that identifies the 
extension namespace. The <el64val:update> element contains one or 
more <el64val:add>, <el64val:rem>, or <el64val:chg> elements, each 
with an "id" attribute identifying the validation. Each 
<el64val:add> and <el64val:chg> element contains an <el64val: 
validationInfo> element, which contains the validation information as 
child element. <el64val:rem> elements do not have child elements. 


In the example below, the validation information consists of a 
<valex:simpleVal> element that identifies the extension namespace. 
The <valex:simpleVal> contains the following child elements: 


o An <el64val:methodID> element that contains an identifier of the 
validation method. 


o An OPTIONAL <el64val:validationEntityID> element that contains an 
identifier assigned to the ENUM Validation Entity. 


o An OPTIONAL <el64val:registrarID> element that contains an 
identifier assigned to the ENUM Registrar by the ENUM Registry. 


o An <el64val:executionDate> element that contains the date that the 
validation was performed. 


o An OPTIONAL <el64val:expirationDate> element that contains the 
date that the validation expires. 
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Example for <update> command: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<command> 
<update> 
<domain:update 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> 
<domain:name>5.1.5.1.8.6.2.4.4.1.4.e164.arpa</domain:name> 
</domain:update> 
</update> 
<extension> 
<el64val: update 
xmlns:el64val="urn:ietf:params:xml:ns:el64val-1.0"> 
<el64val:add id="EK2510"> 
<el64val:validationInfo> 
<valex:simpleVal 
xmlns:valex="urn:ietf:params:xml:ns:el64valex-1.1"> 
<valex:methodID>Validation-X</valex:methodID> 
<valex:validationEntityID>VE-NMO</valex:validationEntityID> 
<valex:registrarID>Client-X</valex:registrarID> 
<valex:executionDate>2004-10-02</valex:executionDate> 
<valex:expirationDate>2005-04-01</valex:expirationDate> 
</valex:simpleVal> 
</el64val:validationInfo> 
</el64val:add> 
<el64val:rem id="EK77"/> 
</el64val :update> 
</extension> 
<c1TRID>ABC-34567</c1TRID> 
</command> 
:</epp> 


Qn@ ACO OOOO. iO: OO. Oy ace, OAs. OO: ONO: OF OQ: OO). I: Acasa 


Figure 5 


When an extended <update> command has been processed successfully, 
the EPP response is as described in the EPP domain mapping [4]. 


6. Formal Syntax 


An EPP object mapping is specified in XML Schema notation. The 
formal syntax presented here is a complete schema representation of 
the object mapping suitable for automated validation of EPP XML 
instances. The BEGIN and END tags are not part of the schemas; they 
are used to note the beginning and ending of the schema for URI 
registration purposes. 
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Formal syntax for Framework: 


BEGIN 

<?xml version="1.0" encoding="UTF-8"?> 

<schema targetNamespace="urn:ietf:params:xml:ns:el64val-1.0" 
xmlns:el64val="urn:ietf:params:xml:ns:el64val-1.0" 
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


giez 
Import common element types. 
=-> 
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" 
schemaLocation="eppcom-1.0.xsd"/> 


<annotation> 
<documentation> 
Extensible Provisioning Protocol v1.0 
domain name extension schema for framework for 
provisioning of E.164 number validation information. 
</documentation> 
</annotation> 


<1-- 

Child elements found in EPP commands. 

--> 
<element name="create" type="el64val:insertType"/> 
<element name="update" type="el64val:updateType"/> 
<element name="renew" type="el64val:insertType"/> 
<element name="transfer" type="el64val:insertType"/> 


<1-- 
Child elements of the <create>, <renew>, and <update> commands. 
--> 
<complexType name="insertType"> 
<sequence> 
<element name="add" type="el64val:addType" 
maxOccurs="unbounded" /> 
</sequence> 
</complexType> 
SITE 
Child elements of the <update> command. 
--> 
<complexType name="updateType"> 
<sequence> 


<element name="add" type="el64val:addType" 
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minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="rem" type="el64val:remType" 
minOccurs="0" 
maxOccurs="unbounded"/> 
<element name="chg" type="el64val:chgType" 
minOccurs="0" 
maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


<a 
Data elements for add, chg and rem. 
--> 
<complexType name="addType"> 
<sequence> 
<element ref="el64val:validationInfo"/> 
</sequence> 
<attribute name="id" type="eppcom:minTokenType" 
use="required"/> 
</complexType> 


<complexType name="chgType"> 
<sequence> 
<element ref="el64val:validationInfo"/> 
</sequence> 
<attribute name="id" type="eppcom:minTokenType" 
use="required"/> 
</complexType> 


<complexType name="remType"> 
<attribute name="id" type="eppcom:minTokenType" 
use="required"/> 

</complexType> 


Ss 
Child elements found in EPP responses 
--> 
<element name="infData" type="el64val:infDataType"/> 


SES 

child elements of the <info> response. 

=-> 

<complexType name="infDataType"> 
<sequence> 
<element name="inf" type="el64val:infType" 
minOccurs="0" 
Hoeneisen Standards Track 
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maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


<= 
Data elements for inf 
--> 
<complexType name="infType"> 
<sequence> 
<element ref="el64val:validationInfo"/> 
</sequence> 
<attribute name="id" type="eppcom:minTokenType" 
use="required"/> 
</complexType> 


<a 
Global elements. 
--> 
<element name="validationInfo" type="el64val:ValidationInfoType" /> 


<= 
Extension framework types. 
--> 
<complexType name="ValidationInfoType"> 
<sequence> 
<any namespace="##other"/> 
</sequence> 
</complexType> 


SiS 

End of schema. 
--> 

</schema> 

END 


Figure 6 
Formal syntax for a simple validation (example): 


BEGIN 

<?xml version="1.0" encoding="UTF-8"?> 

<schema targetNamespace="urn:ietf:params:xml:ns:el64valex-1.1" 
xmlns:el64valex="urn:ietf:params:xml:ns:el64valex-1.1" 
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 
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Import common element types. 


--> 


<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" 


schemaLocation="eppcom-1.0.xsd"/> 


<annotation> 
<documentation> 


Example for E.164 number validation information. 


</documentation> 
</annotation> 


<element name="simpleVal" type="el64valex:simpleValType"/> 


<complexType name="simpleValType"> 
<sequence> 

<element name="methodID" type="el64valex:methodIdType"/> 

<element name="validationEntityID" type="eppcom:clIDType" 


minOccurs="0"/> 


<element name="registrarID" type="eppcom:clIDType" 


minOccurs="0"/> 

<element name="executionDate" type="date"/> 
<element name="expirationDate" type="date" 
minOccurs="0"/> 


</sequence> 
</complexType> 


<simpleType name="methodIdType"> 
<restriction base="token"> 


<minLength value="1"/> 
<maxLength value="63"/> 


</restriction> 
</simpleType> 


== 


End of schema. 


--> 


</schema> 


END 


Figure 7 
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7. IANA Considerations 


This document uses Uniform Resource Names (URNs) to describe XML 
namespaces and XML schemas conforming to the registry mechanism 
described in RFC 3688 [8]. Four URI assignments have been made: 


1. Registration for the extension namespace: 
* URI: urn:ietf:params:xml:ns:el64val-1.0 
* Registrant Contact: See the "Author’s Address" section of this 


document. 
* XML: None. Namespace URIs do not represent an XML 
specification. 


2. Registration for the extension XML schema: 
* URI: urn:ietf:params:xml:schema:el64val-1.0 
* Registrant Contact: See the "Author’s Address" section of this 
document. 
* XML: See Section 6, "Formal Syntax", of this document. 


3. Registration for the extension namespace: 
* URI: urn:ietf:params:xml:ns:el64valex-1.1 
* Registrant Contact: See the "Author’s Address" section of this 


document. 
* XML: None. Namespace URIs do not represent an XML 
specification. 


4. Registration for the extension XML schema: 
* URI: urn:ietf:params:xml:schema:el64valex-1.1 
* Registrant Contact: See the "Author’s Address" section of this 
document. 
* XML: See Section 6, "Formal Syntax", of this document. 


8. Security Considerations 


The mapping extensions described in this document do not provide any 
security services beyond those described by EPP [3], the EPP domain 


name mapping [4], and protocol layers used by EPP. Security 
considerations related to ENUM are described in the "Security 
Considerations" section of the ENUM specification [2]. The security 


considerations described in these other specifications apply to this 
specification as well. 


Validation information often contains sensitive personal information. 
It is RECOMMENDED that validation information in the <info> response 
is only provided to the sponsoring client. 
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